REMARKS 

Claims 1-4, 6-9, 11, 13-19, 21-23 are pending. 
Claims 1-4, 6-9, 11, 13-19, 21-23 are rejected. 
Claims 1-4 and 14-19 are objected to. 
Claims 1, 2, 4, 6, and 21 have been amended. 

Claim Amendments 

Claims 1, 2, 4, 6, and 21 have been amended. Support for the amended claims can be 
found in the application as filed, for example, on page 10. No new matter has been added. 

Claim Objections 

The Examiner objected to claims 1-4 and 14-19. The Examiner indicated that claim 1 
recites "classifying the application data in the transport protocol layer as IP based", on line 6. 
The Examiner argues that IP is layer 3 while transport layer is layer 4, and it is unclear how can a 
transport protocol layer be classified as IP based. See Office Action dated May 12, 2008 (Office 
Action), p. 2. 

As recited in claim 1, it is the application data that is classified in the transport protocol 
layer, not the transport protocol layer itself. In other words, the transport protocol layer is not 
classified as IP based as the Examiner indicates. Thus, the Examiner's confusion on how a 
transport protocol layer can be classified as IP based is not relevant. 

The specification describes how application data can be IP based or non-IP based. The 
Examiner is again referred to Figure. 2. The Examiner mistakenly identified numeral 36 as the 
transport layer. However, 36 includes the transport functions 36 while 30 is the transport layer 
30 with various service access points (SAP) such as the AV SAP 422 and the IP SAP 428. See 
Application, p. 10, 11. 19-26, for example. 

In addition, IP based or non-IP based application data can be encapsulated in the packet 
formed in the transport layer 30. ". . .for this example, the payload field contains the 
encapsulated AV, AV\C, IP or other application data." Application, p. 10,11. 1-2. Accordingly, 
in one example, application data that is received by the transport layer 30 can be an IP based 
packet to be encapsulated in the transport layer 30. In another example, the application data that 
is received by the transport layer 30 can be AV application data that is not IP-based, which is 
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also to be encapsulated in the transport layer 30. As amended, claim 1 recites such 
encapsulation. 

Thus, one skilled in the art would understand that in the transport layer 30, the data can 
be classified as IP or non-IP based. The Applicant respectfully requests that the Examiner 
withdraw the objection to claims 1-4 and 14-19. 

Claim Rejections - 35 U.S.C. 103 

Claims 1-4, 14-19 are rejected under 35 U.S.C. 103(a) as being unpatentable over W. 
Richard Stevens, "UNIX Network Programming", 1990, (hereinafter Stevens) in view of 
Raphaeli et al (US 20030103521, hereinafter Raphaeli). 

Claim 1 recites "classifying the application data in the transport protocol layer as internet 
protocol (IP) based or non-IP based according to the associated service access point after 
receiving the application data through the service access point." 

With respect to claim 1, the Examiner argued that Figure 2 of the application illustrated 
the data classification is outside of the "transportation layer 36". See Office Action, p. 3. 
However, as described above, the Examiner is mistakenly identifying the transport functions 36 
with the transport layer 30. In Figure 2, transport layer 30 clearly includes the classifiers 40. 

The Examiner also argued that the OSI model does not include data classification in the 
transport layer functionality. First, the claims are not limited to only the OSI model. Second, 
assuming that the OSI model does not teach data classification in a transport layer is evidence 
that claim 1 one skilled in the art would not perform such classification in a transport layer. 

The Examiner argues that "Applicant agrees that the data classification is outside of the 
transport layer, which is consistent with the Examiner's position." Office Action, p. 3, referring 
to the Amendment filed February 10, 2009. However, the Examiner is misinterpreting the 
Applicant's remarks. In particular, the Applicant was referring to Stevens, not to the application. 
That is, in Stevens, the choice between AF_INET and AF_UNIX, which the Examiner 
interpreted as classifying as IP or non-IP based, occurred outside of the transport protocol layer. 
In direct contrast, the classification is explicitly recited in claim 1 as occurring in the transport 
protocol layer. 

Thus, the Examiner acknowledges that the references do not teach each and every 
element of claim 1 . That is, the Examiner and the Applicant agree that Stevens, teaches 
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classifying as IP or non-IP based outside of the transport protocol layer, if it teaches such 
classification at all. 

Moreover, Stevens addresses the interface to a protocol layer. It does not address the 
internal operation of the protocol layer. That is, the internal functions of a protocol layer are not 
described in Stevens. For example, there is no section of Stevens cited by the Examiner that 
describes how the address family parameter of a socket system call is used in the functions of the 
protocol layer, but only in the external reference through the socket system call. 

Moreover, Raphaeli is silent on IP, instead describing a powerline MAC layer. Thus, it 
does not suggest using a classification as IP or non-IP in determining if a powerline MAC 
connection exists. The Examiner noted that Raphaeli was not used to teach IP; however, for 
completeness, the Applicant refers to Raphaeli to address all references used in the rejection. 

Furthermore, although the Applicant believes that claim 1 is allowable over the cited 
references, claim 1 has bee amended to recite "if a connection exists for the application data, 
encapsulating the application data into a payload of transport messages." Although Raphaeli 
does mention encapsulation by attaching a header, neither Stevens nor Raphaeli describe 
encapsulation of application data for a connection that was determined in response to a 
classification of the data as IP or non-IP based. See Raphaeli, 1J97. 

Accordingly, as described above, Stevens and Raphaeli do not teach each and every 
element of claim 1, and the Examiner is apparently relying on personal knowledge without 
authority. The Applicant respectfully requests that the Examiner withdraw the rejection of 
claims 1 and dependent claims 2-4, and 14-18. 

Claims 6-7, 9 and 21-23 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Andrew S. Tanenbaum, "Computer Networks", Forth edition, 8/9/2002 (hereinafter Tanenbaum) in 
view of Stevens, further in view of Hogan et al. (US Patent 4,841,456, hereinafter Hogan). 

Claim 6, as amended, recites "determining an order of rules associated with the classifier 
to apply to the data packet using a priority of each of the rules, where each rule includes the 
corresponding priority." That is, each rule includes the priority. 

The Examiner noted that Tanenbaum did not teach the determination of the order of the 
rules. The Examiner cited Figure 6.7 of Stevens to teach the rules. However, Figure 6.7 is only a 
list associating various combinations of family, type, and protocol with an actual protocol. 
Nowhere is there a reference to a priority. 
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The Examiner referenced Hogan to teach the priority. However, Hogan, addresses rules that 
are conditions to take an action in a functional test procedure (FTP). See Hogan, col. 7, 11. 36-53. 
The rules are not rules for classifying a data packet. The Examiner notes that the rules of Hogan are 
"very general and applies to any set of rules." Office Action, p. 12. The Examiner only argued that 
the rules of Tanenbaum in view of Stevens would be applied as in Hogan to "more effectively and 
reasonably implement the rules." However, the example given by Hogan to determine order is 
using the number of parameters. See Hogan col. 8, 11. 29-3 1 . That is, the rule with the most 
conditions is evaluated first. 

In contrast, the "rules" in Figure 6.7 of Stevens as cited by the Examiner, each have the 
same number of parameters. Thus, even assuming that the entries are "rules", Hogan provides no 
indication as to an order of the rules. 

Furthermore, Hogan determines order without using priorities within the rules. That is, as 
described above, Hogan merely counts the number of conditions to determine order. Thus, the 
individual rules in Hogan do not include a priority. In contrast, in claim 6, the order is determined 
using priorities included in the rules. 

Accordingly Tanenbaum, Stevens, and Hogan do not teach each and every element of 
claim 6. The Applicant respectfully requests that the Examiner withdraw the rejection of claim 6 
and dependent claims 7, 9, and 21-23. 

Claim 22 recites that "for each rule associated with audio/visual application data, the rule 
includes only one classification parameter." That is, there is only one classification parameter, 
not multiple classification parameters. 

The Examiner cited the IP address of a customer's house as one parameter. Office 
Action, p. 14. However, the Examiner fails to identify how the IP address is the only parameter. 
That is, if there is another parameter, such as a source address, TCP options, or the like, then 
there is not only one parameter. 

Moreover, this characterization is in direct conflict with the Examiner's previous 
interpretation of a rule. As described above, the Examiner cited Figure 6.7 of Stevens to teach a 
rule. However, the entries in Figure 6.7 include multiple parameters, such as family, type, and 
protocol. Thus, the addition of the "only one parameter" of the IP address, as interpreted by the 
Examiner, results in four parameters, not only one parameter. 
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Accordingly Tanenbaum, Stevens, and Hogan do not teach each and every element of 
claim 22. The Applicant respectfully requests that the Examiner withdraw the rejection of claim 
22 and dependent claim 23. 

Claims 8 is rejected under 35 U.S.C. 103(a) as being unpatentable over Tanenbaum in view 
Stevens and Hogan, further in view of Malkin (US 6272145 Bl). 

Claim 8 is dependent on claim 6. The addition of Malkin does not cure the deficiencies 
of Tanenbaum, Stevens, and Hogan described above with respect to claim 6. For example, 
Malkin does not address priorities within rules and their usage when applying the rules to data 
packets. Instead Malkin focuses on multilink communication. See Malkin, Abstract, and col. 1, 
11. 6-18. Accordingly, Tanenbaum, Stevens, Hogan, and Malkin do not teach each and every 
element of claim 8. The Applicant respectfully requests that the Examiner withdraw the 
rejection of claim 8. 

Claims 1 1, 13 are rejected under 35 U.S.C. 103(a) as being unpatentable over Stevens in 
view of Hogan. 

Claim 1 1 recites that each set of parameters includes a priority, and the sets of parameters 
are used in analyzing the data packet according to an order of the priorities of the sets of 
parameters." As described above, Stevens and Hogan do not teach such an order or priorities 
that are included within the sets of parameters. Accordingly, the Applicant respectfully requests 
that the Examiner withdraw the rejection of claim 1 1 and dependent claim 13. 

For the foregoing reasons, reconsideration and allowance of the claims of the application 
as amended is requested. The Examiner is encouraged to telephone the undersigned at (503) 
222-3613 if it appears that an interview would be helpful in advancing the case. 



MARGER JOHNSON & McCOLLOM, P.C. 
210 SW Morrison Street, Suite 400 
Portland, OR 97204 
503-222-3613 
Customer No. 46404 



Respectfully submitted, 

MARGER JOHNSON & McCOLLOM, P.C. 




Derek Meeker 
Reg. No. 53,313 
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